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(57) Zur Unterstutzung der Interaktion zwischen 
einer ersten Einheit, die gemSB einer ersten Beschrei- 
bungssprachespezifiziert 1st, und einer zweiten Einheit, 
die gemSfB einer zweiten Beschrelbungssprache spezi- 
fiziert ist, werden in beiden Einheiten jeweils Klassen 
zur Verfugung gestelit werden, die die Bearbeitung von 
Typen steuern. In der ersten Einheit und/oder der zwei- 
ten Einheit werden hierbei ein oder mehrere hybride 



Klassen zur Verfugung gestelit, die jeweils sowohl die 
Bearbeitung eines gema3 der ersten Beschreibungs- 
sprache spezifiziertenTyps als auch die Bearbeitung 
eines, diesem Typ entsprechenden, in einen Typen 
gemSB der zweiten Beschreibungssprache konvertier- 
ten Typs steuern. 
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Beschreibung 

Die Erfindung betrifft ein Verfahren zur Unlerstut- 
zung der Interaktion zwischen einer ersten Einheit, die 
gema3 einer ersten Beschreibungssprache spezifiziert 
ist. und einer zweiten Einheit, die gemSB einer zweiten 
Beschreibungssprache spezifiziert ist, nach dem Ober- 
begriff von Anspmch 1, ein Verfahren zur Interaktion 
einer ersten Einheit, die gemSB einer ersten Beschrei- 
bungssprache spezifiziert ist, mit einer zweiten Einheit 
die gemaiB einer zweiten Beschreibungssprache spezi- 
fiziert ist. nach dem Oberbegriff von Anspruch 5, ein 
Computersystem nach dem Oberbegriff von Anspruch 
7, eine Programm-Modul nach dem Oberbegriff von 
Anspruch 10 und eine Rechnereinheit nach dem Ober- 
begriff von Anspruch 1 1 . 

Fur die softwaremSQige Realisierung von verteilten 
Computersystemen wird zunehmend die objektorien- 
tierte Modellierung als Architeklurprinzip verwendet. 

Eine solche Software - Architektur eines Computer- 
systems ist die CORBA - Architektur (CORBA = Com- 
mon Object Request Broker Architecture), die eine 
bedeutende Komponente der von der Object Manage- 
ment Group (OMG) spezifizierten OSA-Architektur 
(OSA = Object Service Architecture) ist. Objekte die 
dieser Spezifikation folgen. im folgenden CORBA- 
Objekte genannt, sind mittels der Beschreibungsspra- 
che CORBA IDL (IDL = interface definition language) 
spezifiziert. Auch sSmtliche Typen eines solchen Objek- 
tes sind in dieser Sprache, also CORBA IDL, spezifi- 
ziert. 

Fur den Bereich des Netzwerkmanagements ist 
von der OS! (Open System Interconnection) ein Objekt- 
modell standardisiert (Management framework for open 
systems interconnection, ITU-T Recommendation 
X.700, 1992). Seine Objekte, die im folgenden OSI- 
Objekte genannt warden, sind in der Beschreibungs- 
sprache ASN.1 (Abstract Syntax Notation) venwendet. 
SSmtliche Typen eines solchen OSI-Objektes sind 
ebenfalls in dieser Sprache, also ASN.1, spezifiziert 

Die Erfindung geht nun davon aus, wie die Bearbei- 
tung von Typen in einem Computersystem normaler- 
weise realisiert ist. Fur jede Typ steht normalenweise 
eine Klasse zur Verfugung, die die Bearbeitung dieses 
einen Typs steuert. 

Soli nun die Interaktion zwischen Objekten. die in 
unterschiedlichen Beschreibungssprachen spezifiziert 
sind, erm6glicht werden, so treten Probleme auf: Die 
Typen sind in den Objekten auf unterschiedliche Weise 
spezifiziert, beispielsweise in ASN. 1 in OSl-Objekten 
und in CORBA-IDL in CORBA Objekten. Fur eine Inter- 
aktion sind deshalb Mechanismen erforderlich, die eine 
Typ-lnteroperabilit&t erm6glichen. 

Der Erfindung liegt nun die Aufgabe zugrunde, die 
Interaktion zwischen Objekten. die in unterschiedlichen 
Beschreibungssprachen spezifiziert sind. zu unterstut- 
zen. 

Diese Aufgabe wird gelSst durch Verfahren nach 



der Lehre von Anspruch 1, und 5, durch ein Computer- 
system nach der Lehre von Anspruch 7, durch eine Pro- 
gramm-Modul nach der Lehre von Anspruch 10 und 
durch ein Rechnereinheit nach der Lehre von Anspruch 
5 11. 

Der Erfindung liegt hierbei der Gedanke zugrunde, 
daB hybride Klassen zur Verfugung gestellt werden. die 
sowohl die Bearbeitung von Typen, die gemSB einer 
ersten Beschreibungssprache spezifiziert sind als auch 

10 die Bearbeitung der korrespondierenden Typen gemSB 
der zweiten Beschreibungssprache steuern. Mittels 
einer solchen hybriden Klasse kOnnen so sowohl Typen 
die in der ersten Beschreibungssprache spezifiziert sind 
im Kontext der zweiten Beschreibungssprache manipu- 

15 liert werden als auch umgekehrt. 

Bei solchen Typen kann es sich vorzugsweise um 
Daten-Typen handeln. Bei Daten Typen handelt es sich 
um Kategorisierung von zu bearbeitenden Operations- 
Argumente, die typischer Weise beides enthalten. 

20 sowohl das VerhaKen als auch die Darstellung. 

Eine Klasse ist ein abstrakter Daten-Typ. der ein 
Oder mehrere statische Oder dynamische Datentypen 
und Operationen, genannt „methode". „verkapselt" 
(encapsulate) also umschlieBt. Eine Klasse ist daruber- 

25 hinaus eine Implementierung, die Objekte (object 
instances), die dieser Objekt-Klasse angehGren und 
alle ein dhnliches Vertiatten zeigen. erzeugen kann. 

Klassen spezifizieren Objekte entsprechend einer 
allgemeinen Implementierung. 

30 Ein weiterer Vorteil dieser Erfindung ist. daB sie 
schnell ist. da Typdefinition und damit die Abbildung vor 
Programmablauf bereits erfolgt ist. Es mussen keine 
Entscheidungen wShrend des Programmablauf. bei- 
spielsweise das Abprufen von Typen. durchgefuhrt wer- 

35 den. 

Besonders Vorteilhaft ist es hierbei, die Erfindung 
auf den Bereich des Netzwerkmanagement anzuwen- 
den, wenn dort sowohl OSI als auch CORBA-Einheiten 
vorhanden sind. Auf Grund des hohen MaBes an Inter- 
40 aktion, das in einer solchen Umgebung notwendig ist, 
ist hier die Anwendung der Erfindung besonders vorteil- 
haft. 

im Folgenden wird die Erfindung anhand eines 
Ausfuhrungsbeispiels unter Zuhilfenahme beiliegender 
45 Zeichnungen beispielhaft erlSutert: 

Fig. 1 zeigt eine Blockschaltbild eines erfindungs- 
gem&Ben Computersystems. 

50 Rg. 2a zeigt eine funktionelle Darstellung einer 
ersten Moglichkeit der Interaktion zwischen unter- 
schiedliche spezifizierten Objekten. 

Rg. 2b zeigt eine funktionelle Darstellung einer 
55 zweiten MGglichkeit der Interaktion zwischen unter- 
schiedliche spezifizierten Objekten. 

Rg. 3a zeigt eine funktionelle Darstellung einer drit- 
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ten Moglichkeit der Interaktion zwischen unter- 
schiedliche spezif izierten Objekten. 

Fig. 3a zeigt eine funktionelle Darstellung einer 
vierten Moglichkeit der Interaktion zwischen unter- 
schiedliche spezif izierten Objekten. 

Fig. 4 zeigt eine logische Darstellung des Inlerope- 
rabilitSts-Prinzips. 

In dem Austuhrungsbeispiel wird die Durchfuhrung 
der erfindungsgemafSen Vertahren in einem ertindungs- 
gemSBen Computersystem beschrieben, das aus 
einem Oder aus mehreren ertindungsgemSBen Rech- 
nereinheiten besteht. auf denen jeweils ein oder meh- 
rere erfindungsgemaBes Programm-Modul ablaufen. 

Fig. 1 zeigt ein Computersystem CS mit drei Rech- 
nereinheiten Ci bis C3. die untereinander kommunizie- 
ren. 

Bei den Rechnereinheiten C1 bis 03 handett es 
sich beispielsweise urn Computer, Drucker oder urn 
Netzetemente eines Kommunikationsnetzes. Sie wei- 
sen jeweils eine Hardware-Plattform, bestehend aus 
Prozessoren, Speichereinrichtungen und peripheren 
Komponenten, eine Software-Piattform. die beispiels- 
weise ein Betriebssystem und ein Datenbanksystem 
umfaBt und Anwendungen auf. die von auf der Soft- 
ware-Plattform ablaufenden Anwendungs-Programm- 
Modulen gebildet werden. Die Rechnereinheiten C1 bis 
C3 Bind durch ein oder mehrere Kommunikationsnetze 
untereinander verbunden, beispielsweise durch X.25, 
#7, Ethernt oder Token- Ring Kommunikationssysteme. 
Die Software-Plattform der Rechnereinheiten CI bis C3 
stent hierbet die notwendigen Datenubertragungsdien- 
ste bereit. 

Die Anwendungs-Programm-Module sind als 
Objekte (Managed objekt) modeiliert, d. h. der Code 
und die Daten eines Objektes werden durch eine 
Summe von Attributen und Funktionen reprSsentiert, 
auf die andere Objekte zugreifen kGnnen. Durch das 
wechselseitige Zugreifen einer Vielzahl solcher Objekte 
werden sodann die Anwendungsfunktionen des Com- 
putersystems CS erbracht. 

GemSB der CORBA-Architektur weisen die Rech- 
nereinheiten C1 bis C3 mehrere Objekte CO und SO 
und mehrere Objekt-Anforderungs-Broker (Object 
Request Broker) ORB auf. 

Aus der Dienstsicht k6nnen die Objekte CO und SO 
jeweils als eine verkapselte Einheit betrachtet werden, 
die einen oder mehrere Dienste zur Verfugung stellt, die 
von einem Kllenten (client) angefordert werden konnen. 
Die Objekte CO fordern hierbei Dienste an (Client 
Object), die von den Objekten SO erbracht werden 
(Server Objects). 

Zum Anfordern eines Dienstes sendet ein CO eine 
Anforderungs-Nachricht (request) an ein SO. Eine sol- 
che Anforderungs-Nachricht enthait hiertei folgende 
Informationen: eine Operation, ein Ziel-Objekt, keinen 



Oder mehrere Parameter und optional einen Anforde- 
rungs-Kontext (request context). Nach Erbringen des 
Dienstes sendet das SO eine Ergebnis-Nachricht (out- 
come) an das CO zunuck. die fur diese Anforderungs- 

5 nachricht definiert ist. 

Zum Senden und zum Empfang der Anforderungs- 
und Ergebnisnachrichten steht den Objekten SO und 
CO eine Schnittstelleneinheit lU zur Verfugung. 

Die Objekt-Anforderungs-Broker (ORB) stellen eine 

10 Infrastruktur zur Verfugung, die es den Objekten 
eriaubt, in einer verteilten Umgebung zu kommunizie- 
ren. Fur die Objekte CO ist es damit nicht von Bedeu- 
tung auf welchem der anderen der Rechnereinheiten 
C1 bis C3 ein Objekt SO, dessen Dienst sie anfordern 

15 wollen, angesiedelt ist und auf welcher speziellen Platt- 
form Oder in welchem Implementierungsverfahren das 
Objekt realisiert ist. 

Jedes Objekt kennt hierzu zumindest einen Objekt- 
Anforderungs-Broker ORB und weiB, wie sie diesen 

20 lokalen Objekt-Anforderungs-Broker zu kontaktieren 
hat. Jeder Objekt-Anforderungs-Broker weiB wie er 
andere Objekt-Anforderungs-Broker kontaktieren kann 
und wie er mit ihnen zu kommunizieren hat. Hierfur Ver- 
wendet er das RPC-Verfahren (RPC = remote proce- 
ss dure call mechanisms). Ein Objekt sendet somit eine 
Anforderungsnachricht und einen der Objekt-Anforde- 
rungs-Broker ORB. die Weiterreichen der Anforde- 
rungsnachricht an das Ziel-Objekt wird durch die von 
den Objekt-Anforderungs-Broker ORB gebildeten 

30 CORBA- Infrastruktur eriedigt. 

Um uber die CORBA-lnfrastruktur mittels CORBA- 
Mechanismen interagieren zu kdnnen und mit anderen 
Objekten auf dieser Infrastruktur zusammenarbeiten zu 
kfinnen, muB jede der Objekte CO und SO uber eine 

35 CORBA spezifische Schnittstelle (Interface) verfugen. 
Ein solche Schnittstelle enthait hierbei eine Beschrei- 
bung eines Satzes von mSglichen Operation, die eine 
anderes Objekt vondiesem Objekt anfordern kann. Die 
Schnittstellen der Objekte sind hiertei in der Beschrei- 

40 bungssprache IDL (Interface Definition Language) defi- 
niert, bei der es sich um eine reine Schniffstellen- 
Beschreibungssprach handelt. Die Vererbung (inheri- 
tance) dieser Interfaces eriaubt es daB ein Objekt meh- 
rere Schnittstellen unterstutzt. 

45 I 

In CORBA wird auf ein Objekt direkt uber diese 
CORBA spezifische Schnittstelle zugegriffen. Die 
Implementierung dieser Schnittstelle ist das Object 
selbst. Es besteht aus Code und Daten und bendtigt 

50 somit keine Ausfuhrungsinstanz (Agent entity), wie dies 
der Fall ist, wenn ein Objekt rein durch eine Datenstruk- 
tur reprasentiert ist. 

Das Computersystem enthait nun neben den 
Objekten CO und SO weitere Objekt, die nicht in Fig. 1 

55 gezeigt sind. Diese sind nicht in CORBA spezif iziert und 
interagieren liber spezielle Schnittstelleneinheiten uber 
die oben beschriebene CORBA-lnfrastruktur unterein- 
ander und mit den Objekten CO und SO interagieren. 
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Die Verwendung solcher hybrider Komponenten 
auf einer CORBA-lnfrastruktur hat hierbei den Vorleil, 
da6 bereits bestehende, gemaB einer anderen Objekt- 
Modell Architektur spezifizierte Objekte wlederverwen- 
det werden kCnnen und eine Zusammenarbeit solcher 5 
Objekte mil CORBA Objekten ermSglicht wird. Dies hat 
vor allem im Bereich des Netzwerkmanagement groBe 
Vorteile. da in diesem Bereich bereits eine Vietzaht von 
Objekten bestehen. die gemSB des OSI-Objektmodells 
spezifiziert sind. OSI-Netzwerkmanagent-Komponen- 10 
ten, beispielsweise Manager, Agent, Mediation Device, 
werden jeweils von einem Oder mehreren solche OSI- 
Objekte gebildet. 

FOr den Bereich des Netzwerkmanagements ist 
von der OSI (Open System Interconnection) ein Objekt- is 
model! standardisiert (Management framework for open 
systems interconnection, ITU-T Recommendation 
X700, 1992). Neben dem Objektmodell (SMI = Struc- 
ture of Management Information) sind auch grundle- 
gende Objekte, ein Set von Management Diensten 20 
(CMIS common management information service defi- 
nition) und ein Netzwerkmanagement-Protokoll (GMIP 
= Common Management Information Protocol) zur 
Kommunikation der Objekte untereinander spezifiziert. 
Objekte sind in der Beschreibungssprache GEMO spe- 25 
zifiziert. die ASN Syntax venwendet und weitere eigene 
Makros enthait 

Der Prinzipielle Unterschied zwischen ..naturlichen" 
CORBA-Objekten und jiaturiichen" OSI-Objeklen 
besteht darin, daB die CORBA Objekte die Implemen- 30 
tierung der CORBA-Schnittstelle darstellen, wohinge- 
gen die OSI-Objekte eines Netzwerkmanagement- 
selements als Datenstruktur im MIB-Datensatz (Mana- 
gement Information Base) abgelegt sind und durch 
einen Agenten, mit dem mittels des CEMIP-Protokolls 35 
kommuniziert wird, manipuliert werden. Daruberhinaus 
sind ihre Datentypen in unterschiedlichen Beschrei- 
bungssprachen spezifiziert, nSmlich in CORBA IDL und 
in ASN.1 und damit nicht kompatibel. 

In Fig. 2a, Fig. 2b, Rg. 3a und Rg. 3b sind nun 40 
mdgliche Implementierungen von OSI Einheiten auf 
einer CORBA Infrastruktur und gleichzeitig M6gliche 
Arten der Interaktion zwischen CORBA Einheiten und 
OSI Einheiten uber eine CORBA Infrastruklur aufge- 
zeigt. Die M6glichkeit der Interaktion uber eine CORBA 45 
Infrastruktur impliziert hierbei solch eine Interaktion zwi- 
schen Einheiten in unterschiedlicher Spezrfizierungs- 
sprache. Es erfordert der gleiche Vorgehensweise. Als 
Einheit wird hierbei ein Gebilde mit einem oder mehre- 
ren Objekten betrachtet. 50 

Fig. 2a zeigt eine Kommunikationsschicht 
CORB/ORB, mehrere uber diese Kommunikations- 
schicht allgemein zur Verfugung stehende Dienste 
CMISE Services, zwei Netzwerkmanagement-Kompo- 
nenten M und A und jeweils zwei zwischen diesen ss 
Objekten und der Kommunikationsschicht CORB/ORB 
gelegenen Kommunikationsfunktionen GMO/C++ und 
CMISE/IDL. 



Bei den Komponenten M und A handelte es sich 
nicht um CORBA-Objekte, sondern jeweils urn ein oder 
mehrere OSI- Objekten OM bzw. OA und einer Mana- 
ger bzw. Agent Funktionseinheit. Jeder der Komonen- 
ten M und A stellt somit eine OSI Einheit dar. Mittels der 
Agent bzw. Manger Funktionseinheit werden Operatio- 
nen auf diesen Objekten ausgefuhrt bzw. Anforderung 
an aridere Objekte versendet. Agent und Manager 
Funktionseinheit kommunizieren uber das CMIP-Proto- 
koll. Aus der Sichtweise des Netzwerkmanagement 
nimmt die Komponente M die Rolle eines Managers 
(Manager) und die Komponente A die eines Agenten 
(Agent) ein. 

Die Kommuniktationseinheit GDMO/C++ besteht 
aus einem oder mehreren speziellen Zugriffs-Objekten, 
die die Ausfuhrung von CMISE Operationen auf den 
Objekt OA oder OM erm5glichen. 

Die CMISE Management Dienste werden durch ein 
CMISE-Objekl auf der Seite des Objektes OA realisiert. 
Die Schnittsteileneinheit CMISE/IDL enthait dieses 
CMISE-Objekt und die diesem Objekt zugeordneten 
Dienste. Das CMISE-Objekt der Schnittsteileneinheit 
CMISE/IDL ist durch ein IDL-lnterface spezifiziert ist 
und agiert und erscheint so nach auBen wie ein 
CORBA-Objekt. Um diese Spezif izierung und damit die 
Bereitstellung einer CORBA-Schnittstelle zu dem 
Objekt OA zu ermGglichen. ist eine Typkonvertierung 
Oder Typ-lnteroperabileiat von ASN.1 in IDL Typen not- 
wendig. Wie diese Type-lnteroperabilit§t en-eicht wird. 
wird spater anhand von Fig. 4 dargestellt. CMISE-Dien- 
ste stellen somit als ein Set von CORBA Objekten zur 
Verfugung. Durch uber die CORBA-lnfrastruktur geleitet 
CORBA-Anforderung k6nnen so CMISE-Operationen 
auf dem Objekt OA ausgefuhrt werden. Gleiches gilt fur 
das Objekt MO 

Eine zweite Mdglichkeit der Anbindung von OSI- 
Einheiten uber eine CORBA-lnfrastruktur ist in Fig. 2b 
aufgezeigt 

Rg. 2b zeigt die Kommunikationsschicht 
CORB/ORB, mehrere liber diese Kommunikations- 
schicht allgemein zur Verfugung stehende Dienste 
CMISE Services, die Objekte OM und OA und jeweils 
zwei zwischen diesen Objekten und der Kommunikati- 
onsschicht CORB/ORB gelegenen Kommunikations- 
funktionen GDMO/IDL und CMISE/IDL 

Durch die Schnittsteileneinheit GDMO/IDL werden 
die in GDMO spezifizierten OSI-Objekte der Kompo- 
nenten A und M in eine Spezifikaton als IDL Schnitt- 
steile ubersetzt. Auf ein so spezifiziertes Objekt kann 
durch Wassische CORBA-Nachrichten zugegriffen wer- 
den. Jedes dieser OSI-Objekt wird somit in ein reines 
CORBA Objekt transformiert. Da die Spezifikation in 
IDL und ASN.1 von unterschiedlicher Natur sind 
(Schnittstellenbeschreibung <- ) Objekl-Spezif ikation) ist 
keine vollkommene Ubersetzung mdglich und nur ein 
Untermenge von CMISE-Diensten wird uber die 
Schnittsteileneinheit GDMO/IDL angeboten. Dies 
bedeute, daB nur eine Untermenge von CMISE Opera- 
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tionen auf den transformierten CORBA-Objekten aus- 
fuhrbar ist. 

In Fig. 3a und Fig. 3b sind weitere MOglichkeiten 
der Interaktion zwischen Netzwerkmanagement-Kom- 
ponenten dargestellt wobei hier ein Gateway GATE ein- 
gebunden wird. Die genaue Funktionsweise ergibt sich 
aus der Darstellung in den Figuren 3a und 3b zusam- 
men mit der Beschreibung der korrespondieren Einhei- 
ten, die bereits in der Beschreibung zu den Figuren 2a 
und 2b gemacht wurde. 

Die Typinteroperabilitat wird nun wie folgt erreicht : 

Typen im ISO Kontext sind in der Beschreibungs- 
sprache ASN.1 und Typen im CORBA Kontext in in 
der Beschreibungssprache IDLdefiniert. Die erfor- 
derliche Unterstutzung fur dies Typen in jedem 
Kontext muBgesteuert werden. Diese UnterstDtzen 
ist jeweils in Klassen imptementiert. sowohl in 
CORBA Einheiten als auch in OS! Einheiten. Als 
Klassen werden hierbei folgende gewdhit: 

• Die Klassen, die die Unterstutzung der Typen 
in der Beschreibungssprache IDL in CORBA 
Einheiten bereitstellen. Diese Klassen werden 
im folgenden lldIG Klassen genannt. Hierbei ist 
anzumerken, da3 normalenweise eine Klasse 
fur einen Typ zustandig ist. 

• Die Klassen, die die Unterstutzung der Typen 
in der Beschreibungssprache ASN.1 in OSI 
Einheiten bereitstellen. Diese Klassen werden 
im folgenden AsnG Klassen genannt. 

Das Vorgehensweise ist zweigeteilt. Dies wird im 
Folgenden anhand eines Sender/ EmpfSnger Paars 
aufgezeigt: 

Um die Behandlung von IdIG Typen In einer OSI 
Einheit zu unterstutzen. wird der korrespondie- 
rende AsnG Typ aus dem IdIG Typ konstruiert. Hier- 
fur wird ein ^constructor", also ein Steuerelement 
zum erzeugen eines Programm-Objekts zu der 
Klasse hinzugefugt, die den AsnG Typ unterstutzt. 
Dieser ^construdor" nimmt eine IdIG Typen als 
Parameter. Dadurch unterstutzt diese AsnG Klasse 
auch die Bearbeitung des korrespondierenden IdIG 
Typs. 

Um die Venwendung von AsnG Typen. in einer 
CORBA Einheit zu ermdglichen, wird der AsnG Typ in 
den korrespondierenden IdIG Typen transformiert. Dies 
wird dadurch erreicht. daB eine neue Funktion zu der 
Klasse hinzugefugt wird, die diesen AsnG Typen unter- 
stutzt. Diese Funktion nimmt den AsnG Typen als Para- 
meter und giebt den korrespondierenden IdIG Typen 
zuruck. 

Fig. 4 zeigt nun eine logische Darstellung dieses 
Interoperabilitats-Prinzips: 



Fig. 4 zeigt die Einheit SEM und die Klasse GLASS. 
Die Einheit SEM stelltdiegesammte Semantik, den 
Inhalt eines Objektes. dar. Ein Teil davon ist die Klasse 
CLASS, die Syntaxbeschreibungen behandelt. Diese 

5 Klasse CLASS empf&ngt Typen unterschiedlicher Syn- 
tax, Typen in der Beschreibungssprache IDL und 
ASN.1. Sie liefert unterststutzung fur die korrspondie- 
rende unterschiedliche Typen IdIG und AsnG. Die 
Unterstutzung der IdIG Typen wird hierbei wie oben 

10 beschrieben bereitgestellt, indem uber einen „constru- 
cor" IdIG Typen erzeugt und uber ein Funktion AsnG 
Typen in IdIG Typen konvertiert werden. 

Patentanspruche 

15 

1. Verfahren zur Unterstutzung der Interaktion zwi- 
schen einer ersten Einheit, die gemSQ einer ersten 
Beschreibungssprache spezifiziert ist, und einer 
zweiten Einheit, die gemSB einer zweiten Beschrei- 

20 bungssprache spezifiziert ist, wobei den beiden 
Einheiten jeweils Klassen zur Verfugung gestellt 
werden, die die Bearbeitung von Typen steuern, 
dadurch gekennzeichnet, daB der ersten Einheit 
und/oder der zweiten Einheit ein oder mehrere 

25 hybride Klassen zur Verfugung gestellt werden, die 
jeweils sowohl die Bearbeitung eines gemSB der 
ersten Beschreibungssprache spezifizierten Typs 
als auch die Bearbeitung eines, diesem Typ ent- 
sprechenden, in einen Typen gemSB der zweiten 

30 Beschreibungssprache konvertierten Typs steuern. 

2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, daB als erste Spezifizierungssprache fur die 
Spezifizierung von Typen ASN.1 venwendet wird. 

35 

3. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, daB als zweite Spezifizierungssprache fur die 
Spezifizierung von Typen CORBA-IDL venwendet 
wird. 

40 

4. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, daB die hybride Klasse oder die hybriden Klas- 
sen ein Konvertierung zwischen Typen gemaB der 
ersten Beschreibungssprache und Typen gemaB 

45 der zweiten Beschreibungssprache durchfuhren. 

5. Verfahren zur Interaktion einer ersten Einheit, die 
gemaB einer ersten Beschreibungssprache spezifi- 
ziert ist, mit einer zweiten Einheit, die gem§B einer 

50 zweiten Beschreibungssprache spezifiziert ist, 
wobei der ersten Einheiten Klassen zur Verfugung 
gestellt werden, die die Bearbeitung von Typen 
steuern, 

dadurch gekennzeichnet, daB der ersten Einheit 
55 ein Oder mehrere hybride Klassen zur Verfugung 
gestellt werden, die jeweils sowohl die Bearbeitung 
eines gemSB der ersten Beschreibungssprache 
spezifizierten Typs als auch die Bearbeitung eines. 
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diesem Typ entsprechenden, in einen Typen 
gemSB der zweiten Beschreibungssprache konver- 
tierten Typs steuern. 

6. Verfahren nach Anspruch 5, dadurch gekennzeich- s 
net, daB die erste Einheit von zumindest einem 
Objekt gebildet wird und daB die hybride Klasse 
Oder eine der hybriden Klassen im Interface dieses 
Objektes angeboten wird. 

10 

7. CJomputersystem mit mindestens einer ersten Ein- 
heit, die gemaB einer ersten Beschreibungsspra- 
che spezifiziert ist und mit mindestens einer 
zweiten Einheit, die gemSB einer zweiten Beschrei- 
bungssprache spezifiziert ist, wobei den beiden 75 
Einheiten jeweils Klassen zur Verfugung stehen, 

die die Bearbeitung von Typen steuern, 
dadurch gekennzeichnet, dal3 der ersten Einheit 
und/oder der zweiten Einheit ein oder mehrere 
hybride Klassen zur Verfugung stehen, die so aus- 20 
gestaltet sind, daB sie jeweils sowohl die Bearbei- 
tung eines gemdB der ersten Beschreibungs- 
sprache spezrfizierten Typs als auch die Bearbei- 
tung eines, diesem Typ entsprechenden, in einen 
Typen gemSB der zweiten Beschreibungssprache 25 
konvertierten Typs steuern. 

8. Verfahren nach Anspruch 7. dadurch gekennzeich- 
net. daB die erste Einheit eine OSI-Einheit ist. 

30 

9. Verfahren nach Anspruch 7, dadurch gekennzeich- 
net, daB die zweite Einheit eine CORBA-Einheit ist 

10. Programm-Modul, das gemdB einer ersten 
Beschreibungssprache spezifiziert ist und in dem 35 
ein Oder mehrere Klassen zur Verfugung stehen, 

die die Bearbeitung von Typen steuern, 
dadurch gekenrizeichnet, daB in dem Programm- 
Modul ein oder mehrere hybride Klassen zur Verfo- 
gung stehen. die so ausgestaitet sind. daB sie 40 
jeweils sowohl die Bearbeitung eines gemaB der 
ersten Beschreibungssprache spezifizierten Typs 
als auch die Bearbeitung eines, diesem Typ ent- 
sprechenden. in einen Typen gemSB der zweiten 
Beschreibungssprache konvertierten Typs steuern. 45 

11. Rechnereinheit auf der ein Programm-Modul nach 
Anspruch 10 abiauft. 
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